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1.  Introduction 


The  Network  Seienee  Researeh  Laboratory  (NSRL),  formerly  the  Wireless  Emulation 
Laboratory  (WEE),  of  the  US  Army  Research  Laboratory  (ARE)  is  able  to  conduct  multiple 
experimentations  that  involve,  but  are  not  limited  to,  emulating  a  wireless  tactical  network 
environment.  This  is  accomplished  by  running  software  applications  to  create  the  emulation 
environment  under  which  experiments  can  be  conducted.  This  includes  some  internal  and 
external  applications  such  as  the  Dynamically  Allocated  Virtual  Cluster  (DAVC),  Extendable 
Mobile  Ad-hoc  Network  Environment  (EMANE),  Common  Open  Research  Emulator  (CORE),' 
and  the  Scripted  Display  Tools  (SDT3D). 

One  particular  application  that  is  being  used  is  CORE  (version  4.5svn4  [20130716]),  a  Python- 
based  software  application  for  building  a  representation  of  computer  networks  that  runs  in  real¬ 
time.  These  networks  can  be  visualized  using  CORE’S  graphical  user  interface  (GUI)  to  draw 
nodes  and  the  network  connections  that  exist  between  them.  There  are  two  methods  in  which 
CORE  calculates  the  network  connectivity  of  nodes  within  the  GUI:  I)  using  a  distance-based 
formula  or  2)  using  EMANE  (version  0.8.1).  By  using  EMANE,  CORE  takes  advantage 
EMANE’s  ability  to  calculate  node  connectivity  based  on  the  waveform  of  the  radio  model  used 
by  each  node  along  with  that  node’s  global  positioning  system  (GPS)  information. 

The  version  of  CORE  that  is  being  used  only  considers  the  distance-based  formula  to  draw  links 
on  the  GUI  to  represent  network  connectivity.  This  model  works  by  calculating  the  pixel 
distance  between  two  nodes  positioned  on  the  GUI  surface  then  comparing  the  transposed  pixel 
distance  into  meters  whereby  it  can  be  compared  to  the  maximum  allowable  distance  between 
nodes.  If  the  calculated  distance  is  less  than  or  equal  to  the  maximum  distance  value,  the  link  is 
drawn.  Previously,  there  existed  no  method  to  subsequently  draw  those  same  links  if  EMANE  is 
used  to  compute  network  connectivity. 

This  report  describes  a  process  for  adding  a  service  to  the  CORE  application  that  will  gather  one- 
hop  information  and  display  that  information  on  the  CORE  GUI  and  additionally  on  the  SDT3D 
interface. 


2.  Approach/Concept 


Because  there  is  no  existing  method  to  extract  link  information  from  a  CORE  node  when  using 
EMANE  network  parameters,  an  approach  to  gathering  node  link  information  needed  to  be 
developed  in  order  to  draw  the  links  using  the  CORE  GUI  and  scripted  display  tool  (SDT).  The 
approach  that  was  developed  involved  having  each  node  obtain  its  route  information  using  the 
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“ip”  command,  which  is  standard  on  most  Linux  distributions.  Given  the  appropriate 
argument(s),  this  eommand  ean  display  the  eontents  of  the  routing  tables  or  the  route(s)  seleeted 
by  some  criteria.  Once  the  one-hop  routes  were  determined,  a  struetured  eommand  eould  be  sent 
to  the  CORE  GUI  to  draw  the  link  between  that  node  and  eaeh  of  the  one-hop  routes  that  exists. 
Given  that  the  nodes  are  expeeted  to  be  mobile,  the  routes  eould  ehange  over  time,  thus  ereating 
a  need  to  periodically  check  the  routing  table  for  updates/changes.  This  would  provide  a  method 
to  eheck  if  previous  routes  were  still  present  to  determine  if  they  needed  to  be  removed  from  the 
CORE  GUI. 


3.  CORE  Services 


In  CORE,  the  concept  of  serviees  is  used  to  indicate  what  funetionalities  are  enabled  when  a 
node  is  aetivated.  These  functionalities  eould  be  certain  proeesses  or  seripts  that  are  initialized  or 
launehed  when  the  node  is  started.  In  order  to  ineorporate  a  proeess  to  draw  links  when  using 
EMANE  as  an  available  service  to  CORE  nodes,  the  following  elements  within  CORE  needed  to 
be  modified  or  ereated:  CORE  daemon.  Hook  Seript,  Service  Eile,  and  Draw  Links.py. 

3.1  CORE  Daemon 

In  order  to  ereate  the  One  Hop  Links  drawing  funetionality  as  a  serviee  within  CORE,  there 
were  a  few  modifieations  that  needed  to  be  made  to  the  CORE  eode  to  allow  usage  of  the 
existing  methods  that  draw  links  under  the  basie  range  model.  In  partieular,  there  were  two  files 
(cored  and  nodes  .  py)  that  needed  to  be  updated  in  order  to  aehieve  this  funetionality.  Eor 
cored,  line  591  needed  to  be  ehanged  to  the  following  line: 

if  not  isinstance (netcommon,  pycore . nodes . WlanNode )  and  \ 

not  isinstance (netcommon, 
pycore . nodes . EmaneNode ) : 

continue 

In  the  nodes.py  eode,  line  65  needed  to  be  changed  to  the  following  eode: 

def  link(self,  netifl,  netif2) : 
pass 

def  unlink (self,  netifl,  netif2) : 
pass 


3.2  Hook  Script 

Additionally,  a  hook  seript  was  ereated  in  order  to  provide  the  eorreet  mapping  of  node  name 
and  IP  address  as  they  exist  in  the  CORE  environment  when  the  emulation  is  started.  Hook 
seripts  are  optional  seripts  that  are  run  on  eaeh  of  the  host  when  the  emulation  reaehes  a 
specified  state.  Currently,  hook  scripts  can  reside  in  the  following  six  states:  Definition, 
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Configuration,  Instantiation,  Runtime,  Datacollect,  and  Shutdown.  An  example  Runtime  hook 
script  is  shown  in  Fig.  1 . 


Fig.  1  Runtime  hook  script 

The  hook  scripts  shown  in  Fig.  1  gathers  the  IP  address  from  each  of  the  nodes  in  the  CORE 
emulation  environment  along  with  its  node  ID  and  places  it  in  a  temp  folder  that  gets  creating 
when  a  CORE  session  is  started.  The  temp  folder  is  named  according  to  the  session  ID; 
therefore,  if  the  CORE  session  has  an  ID  of  “54356”  the  folder  created  for  that  session  would  be 
“/tmp/pycore. 54356”.  Within  that  folder,  a  file  named  “addressmap”  would  be  created  using  the 
above  hook  script.  The  purpose  behind  creating  this  file  in  this  location  is  so  that  it  is  accessible 
to  all  nodes  during  the  time  of  the  emulation.  When  the  CORE  session  ends,  this  folder  is 
removed  along  with  all  of  its  contents. 

3,3  Service  File 

In  order  to  get  CORE  to  add  a  custom  service  as  part  of  its  set  of  available  services,  as  pictured 
in  Fig.  2,  a  service  file  must  be  created.  Service  files  provide  a  method  in  which  application  can 
be  launched  on  the  nodes  participating  in  the  CORE  emulation  without  having  to  log  onto  each 
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node  individually.  Custom  service  files  can  reside  within  any  directory  on  the  system,  but  the 
location  of  the  custom  files  needs  to  be  defined  in  the  CORE  configuration  file  (i.e., 
/etc/core/core. conf).  This  file  is  read  each  time  the  CORE  daemon  (cored)  is  started. 


Fig.  2  Services  on  Node  3 


Figure  2  shows  which  services  or  applications  will  be  launched  on  Node  3  when  the  CORE 
emulation  is  started.  The  services  that  will  be  launched  are  highlighted  when  selected  and  the 
remaining  services  will  not  be  activated  even  though  they  may  be  available  for  the  node  to  use. 


The  service  can  be  edited  on  each  node  individually  by  clicking  on  the  wrench  icon 


that 


resides  next  to  the  service  name.  By  clicking  the  wrench  icon,  a  pop-up  window  appears  showing 
what  command  will  be  executed  on  startup  and  shutdown  of  the  emulation  along  with  what 
additional  files  will  be  used  and  any  per  node  directories  the  application  needs.  Figure  3  shows  a 
depiction  of  the  pop-up  widow.  The  operations  that  get  populated  into  this  window  by  the  service 
is  defined  within  the  service  file  (Appendix  A).  This  service  file  was  created  using  examples 
provided  by  CORE  and  following  the  structure  in  which  CORE  calls  its  currently  built-in 
services.  The  service  One_Hop_LirLks  starts  a  Python  script  called  draw_lirLks.py,  which  is 
explained  in  the  next  section. 
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Fig.  3  Edit  service  window 

3,4  DrawLinks.py 

The  Python  script  draw_links.py  was  created  to  read  the  route  table  of  a  node,  determine  the 
node’s  one-hop  neighbors,  and  then  send  a  message  command  to  CORE  to  draw  a  line 
representing  that  link.  The  command  is  started  on  each  node  that  has  the  One  Hop  Link  service 
activated  with  the  following  three  parameters:  1)  the  location  of  the  addressmap  file,  2)  the  id  of 
the  node,  and  3)  the  IP  of  the  CORE  API  host  node.  This  script  uses  the  addressmap  file  to 
correlate  IP  address  listed  in  the  route  table  with  the  correct  node  name  in  order  to  construct  the 
proper  message  that  needs  to  be  sent  to  CORE  to  draw  a  link.  The  IP  addresses  that  get  selected 
from  the  routing  table  are  determined  based  upon  the  value  in  the  metric  column.  This  value 
signifies  the  number  of  hops  that  it  takes  for  the  node  to  form  a  route  to  the  selected  IP.  In  our 
case,  we  specify  two  different  metric  values  based  upon  the  routing  protocol  that  is  used.  If  Open 
Shortest  Path  First  (OSPF)  is  used,  one-hop  routes  have  a  metric  value  of  “2”  while  Optimized 
Link  State  Routing  (OLSR)  has  a  metric  value  of  “1”.  The  script  currently  determines  which 
protocol  is  running  on  the  node  and  using  the  metric  value  that  corresponds  to  that  protocol. 
There  currently  is  not  a  default  metric  value  if  the  node  uses  an  alternate  routing  protocol  besides 
the  ones  mentioned  above.  As  other  routing  protocols  get  added  to  CORE,  this  feature  can  be 
adjusted  to  reflect  those  changes. 
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The  message  that  the  seript  eonstruct  to  draw  the  link  between  two  nodes  eonsist  of  both  end 
points  of  that  link.  The  seript  uses  the  id  of  the  node  to  determine  the  beginning  end  point  while 
using  the  node  name  given  by  the  addressmap  file  to  determine  the  ending  end  point.  The 
message  that  is  send  to  CORE  is  shown  below: 

coresendmsg  link  flags=add  type=0  nlnumber=2  n2number=3  -a 
172.16.0.254 

The  sample  message  sends  a  eommand  to  the  CORE  applieation  programming  interfaee  (API), 
residing  at  IP  address  1 72. 1 6.0.254,  that  adds  a  link  between  node  2  and  node  3.  In  order  to 
remove  that  link  onee  the  route  goes  away,  the  same  message  would  be  sent  replaeing 
f  lags=add  with  f  lags=del.  By  enabling  the  ehanges  that  were  made  to  eored  (CORE 
daemon)  earlier  in  this  report,  when  the  message  is  sent  to  the  CORE  API  the  appropriate 
message  is  forwarded  along  to  SDT  as  well. 


4.  Summary  and  Conclusion 


The  deseription  of  the  CORE  serviee  that  was  defined  in  this  report  addresses  a  gap  that  existed 
within  the  CORE  emulation  environment  where  node  links  were  not  drawn  when  the  EMANE 
network  parameters  were  used.  This  report  deseribes  a  method  for  determining  routes  between 
nodes  based  upon  a  metrie  value  and  displays  those  links  on  the  CORE  GUI  and  in  SDT.  This 
serviee  ean  be  started  or  stopped  using  the  CORE  serviees  GUI  and  has  been  tested  within  the 
Network  Seienee  Researeh  Eab. 
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The  following  is  the  One  Hop  Links  CORE  service  file. 

####################################################### 

#  ARL 

# 

#  author:  Rommie  Hardy  <rommie . 1 . hardy . civ@mail . mil> 

####################################################### 


one  hop  links. py:  pushes  link  message  to  cored  to  draw  links  on  COR 
GUI  and  SDT  based  on  routing  table. 

f  f  f 


import  os 

class  Draw  Links (CoreService ) : 

'''  Parent  class  for  ARL  services.  Defines  properties  and  methods 
common  to  ARL ' s  processes. 

T  f  f 

name  =  "One  Hop  Links" 
group  =  "WEL" 

~controlip  =  ("172.16.0.254",  ) 

_depends  =  ( ) 

_dirs  =  0 
_configs  =  () 
startindex  =  50 
startup  =  ("draw  links. py",  ) 
shutdown  =  ("killall  draw  links. py",) 

@classmethod 

def  getstartup (els ,  node,  services): 

' ' '  Return  a  string  that  will  be  written  to  filename,  or  sent 
to  the  GUI  for  user  customization. 

T  T  f 

cmd  =  els ._startup [0] 

cmd  +=  "  %s/addressmap"  %  node . session . sessiondir 
cmd  +=  "  %s"  %  node . name 

cmd  +=  "  --cntrl  ip  %s"  %  els.  controlip 
return  (cmd,  ) 

#  this  line  is  required  to  add  the  above  class  to  the  list  of 
available  services 

addservice (Draw  Links) 
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The  following  is  the  Draw  links  elass  file. 

# ! /usr/bin/env  python 

####################################################### 

#  ARL 

# 

#  author:  Rommie  Hardy  <rommie . 1 . hardy . civ@mail . mil> 

# 

####################################################### 

import  os,  sys,  time 
import  subprocess 
import  socket 
import  argparse 


class  Draw  links: 

def  init  (self  ) : 

f  f  f 

Initialization 

f  f  f 

self .metric  =  '  ' 
self. node  line  =  {} 
self. first  =  True 

def  getAddressMap ( self ,  AddressMap) : 

f  f  f 

Grab  the  address  mapping  key  from 
/tmp/pycore . {Session } /addressmap 

T  f  T 

self . node_list  =  {} 

map  file  =  open (AddressMap,  "r") 

for  line  in  map  file . readlines ( ) : 
node  =  line.splitO  [0] 
ip  =  line.splitO  [1] 

if  not  self. node  list. has  key(node) : 
self . node_list [node]  =  [ip] 

else : 

self . node_list [node] .append(ip) 
map_f ile . close ( ) 
return  self. node  list 
def  getNodelD ( self ,  node_ip) : 

f  f  f 

Determine  the  Node  ID  when  an  IP  address  is  given 

T  f  f 

for  node,  ip  in  self. node  list . iteritems ( ) : 
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if  node  ip. strip  ()  in  ip: 
return  node 

return 

def  getNodelD  List (self,  node  list) : 

f  f  f 

Determine  the  Node  IDs  when  a  list  of  IP  addresses  is  given 

f  f  f 

result_list  =  [] 

for  node  in  node  list: 

item  =  self . getNodelD (node) 
if (item) : 

result  list . append (item) 

self. first  =  False 

return  result  list 

def  checkServices ( self )  : 

' ' '  Grab  which  services  are  running 

This  is  to  determine  which  metric  value  to  use 
OLSR:  metric  =1 
OSPF:  metric  =2 

f  f  f 

DEVNULL  =  open (os . devnull ,  'wb') 

cmd  ospf  =  "ps  aux  | grep  ospf  | grep  -v  grep" 
cmd  olsr  =  "ps  aux  | grep  olsr  | grep  -v  grep" 

ospf_status  =  subprocess . call (cmd_ospf,  shell=True, 
stdout=DEVNULL) 

olsr_status  =  subprocess . call (cmd_olsr,  shell=True, 
stdout=DEVNULL) 

if  ospf_status  ==  0  and  olsr_status  ==  1: 
self. metric  =  "2" 

elif  ospf_status  ==  1  and  olsr_status  ==  0: 
self. metric  =  "1" 

else : 

print  "OLSR  nor  OSPF  are  running" 
exit  ( ) 

return  self. metric 

def  getRoutes ( self ,  metric): 

' ' '  Grab  the  info  from  the  Routing  table 

f  f  f 

self . One_hop_routes  =  [] 

cmd  =  'ip  -4  route  | grep  "metric  %s"  | awk  \'{  print  $1 

} \ '  %  (metric) 
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self. one  hop  list  =  os .popen (cmd) 
for  node  ip  in  self. one  hop  list: 

self . One_hop_routes . append (node_ip) 

return  self. One  hop  routes 

def  addlink ( self ,  nodel,  node2,  cntrl  ip) : 

' ' '  Create  and  send  the  message  that  CORE  needs  to  add  link 
between  two  nodes 

f  f  f 


#  attr  =  "  line  green" 

#  self . session . sdt . cmd (' link  %s,%s%s'  %  (nodelnum,  node2num, 

attr)  ) 

#  Directly  send  to  SDT 

cmd  =  "coresendmsg  link  flags=add  type=0  nlnumber=%s 
n2number=%s  -a  %s"  %  (nodel . Istrip (' n ') ,  node2 . Istrip ( ' n ' ) ,  cntrl  ip) 
print  cmd 
os .popen (cmd) 

def  dellink ( self ,  nodel,  node2,  cntrl  ip) : 

' ' '  Create  and  send  the  message  that  CORE  needs  to  delete 
link  between  two  nodes 


cmd  =" coresendmsg  link  flags=del  type=0  nlnumber=%s 
n2number=%s  -a  %s"  %  (nodel . Istrip (' n ') ,  node2 . Istrip (' n ') ,  cntrl  ip) 
print  cmd 
os .popen (cmd) 

######################  main  body 

########################################### 

time . sleep  (20) 

Draw  =  Draw  links () 


n=0 


parser  =  argparse . ArgumentParser ( ) 

parser. add  argument ( "addressMap" ,  help  =  "file  created  by  CORE  to  map 
node  id  to  node  ip  in  CORE") 

parser. add  argument ( "node  id",  help  =  "id  of  the  node") 
parser. add  argument ( "-c" , "--cntrl  ip",  help  =  "ip  of  the  control 
network  for  CORE  on  host",  default  =  "172.16.0.254") 

args  =  parser . parse_args ( ) 


while  n  !=  5: 
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try : 

with  open (args . addressMap)  as  file: 
break 

except  lOError  as  e: 
n  +=1 

print  "Looking  for  file,  %s."  % (args . addressMap) 
time . sleep (5 ) 
finally : 

if  n  ==  5: 

print  "GIVING  UP ! ! " 

print  "File,  %s,  was  not  found!!"  % (args . addressMap) 
exit  ( ) 


first  run=True 

#  The  variable  "metric"  could  also  be  passed  in  from  startup  through 
CORE  services  but  requires  a  bit  of  investigation 

metric  =  Draw . checkServices ( ) 

node  map  =  Draw. getAddressMap (args . addressMap) 

if  first  run: 

01d_0neHops  =  [] 

while  True: 
try : 

OneHopList  =  Draw. getRoutes (metric) 

OneHop  NodelD  List  =  Draw . getNodelD  List (OneHopList) 


Delete  a  link 

f  f  f 

for  elem  in  set (Old  OneHops) : 
if  Old  OneHops . count (elem) != 

OneHop  NodelD  List . count (elem) : 

print  "Delete  old  link:  ",elem 

Draw . dellink (args . node  id,  elem,  args . cntrl  ip) 


Add  a  new  link 

f  f  f 

for  elem  in  set (OneHop  NodelD  List) : 

if  OneHop  NodelD  List . count (elem) != 

Old  OneHops . count (elem) : 

print  "Add  new  link:  ",elem 

Draw . addlink (args . node  id,  elem,  args . cntrl  ip) 

Old  OneHops  =  OneHop  NodelD  List 
first  run  =  False 
time . sleep ( 1 ) 
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except  Keyboardinterrupt : 

for  elem  in  set (OneHop  NodelD  List) : 

Draw . dellink (args . node  id,  elem,  args . cntrl  ip) 
exit  ( ) 
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The  following  is  the  IP-address-hook  seript. 


# ! /bin/ sh 

#################################################################### 

# 

#  author:  Jeff  Ahrenholz,  BOEING,  < j ef f rey .m . ahrenholz@boeing . com> 

# 

# 

#  modified  by:  Rommie  Hardy  <rommie . 1 . hardy . civ@mail .mil> 

# 

#################################################################### 

#  this  is  a  runtime  hook  that  gathers  all  IP  addresses  from  nodes  and 
puts  them  in  a 

#  /tmp/pycore . nnnnn/addressmap  file 

LOGFILE=$ { SESSION_DIR} /addressmap 
PIDFILES='ls  -d  ${SESSION_DIR}/* .pid' 

#  this  script  only  grabs  the  IP  address  of  this  interface,  but  can  be 
extended  for 

#  multiple  interfaces 

#  DEV=ethO 

#  echo  "#  session  ${SESSION}  address"  >  ${LOGFILE} 

for  PIDFILE  in  $ { PIDFILES } ;  do 

PIDNAME='basename  $PIDFILE' 

#echo  $PIDFILE  »  ${LOGFILE} 

#  this  strips  off  the  ".pid"  to  get  the  channel  name 
NODECHANNEL='echo  ${PIDFILE}  | sed  's/.pid//g'' 

#  echo  $NODECHANNEL  »  ${LOGFILE} 

#  this  gets  the  devices  from  all  nodes 

DEV='vcmd  -c  $ {NODECHANNEL }  --  ip  -4  addr  | grep  inet  | awk  '/eth/ 
{print  $5 } ' ' 

for  dev  in  $DEV;  do 

#  this  gets  a  string  like  "  inet  10.0.0.1/32  scop  global 

ethO  " 

IPSTR='vcmd  -c  $ {NODECHANNEL }  --  ip  -4  addr  show  dev  ${dev} 

I grep  inet' 

IP='echo  $IPSTR  |  awk  '{  print  $2; 

IP='echo  ${IP%/32}  ' 

NODE='basename  $ {NODECHANNEL } ' 
echo  "$NODE  $IP"  »  ${LOGFILE} 

done 

done 
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